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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the protocols for connection management of packet data on signalHng channels which is 
applied on the air interface, the PDSSl protocol and the PDSS2 protocol. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 02.63: "Digital cellular telecommunications system (Phase 2+); Packet Data on Signalling 

channels service (PDS) Service description. Stage 1". 

[6] GSM 03.63: "Digital cellular telecommunications system (Phase 2+); Packet Data on Signalling 

channels service (PDS) Service description. Stage 2". 

[3] GSM 04.06: "Digital cellular telecommunications system (Phase 2+); Mobile Station - Base 

Station System (MS - BSS) interface Data Link (DL) layer specification". 

[4] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

signalling layer 3 General aspects". 

[5] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

layer 3 specification". 

[7] GSM 08.56: "Digital cellular telecommunications system (Phase 2+); Base Station Controller - 

Base Transceiver Station (BSC - BTS) interface Layer 2 specification". 



3 Definitions and abbreviations 

3.1 Definitions 

Definitions used in the present document are also defined in GSM 02.63 and GSM 04.07. 
Idle phase: A protocol entity is in the idle phase when. 

TI flag: See GSM 04.07. 

Transaction Identifier (TI): See GSM 04.07. 

3.2 Abbreviations 

Abbreviations used in the present document are also listed in GSM 0L04 [1]. 
For the purposes of the present document, the following abbreviations apply: 
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CM: Connection Management 

MM: (See GSM 04.07) 

PDSSl: Packet Data on Signalling channels Service 1 

PDSS2: Packet Data on Signalling channels Service 2 

RR: (See GSM 04.07) 

TI: Transaction Identifier 



Applicability 



Support of the PDSSl protocol is optional in the mobile station and in the network. Support of the PDSS2 protocol is 
optional in the mobile station and in the network. 

If a mobile station supports the PDSSl protocol, it must support it on both the main and the slow associated data link. 



Main concepts 



The present document specifies the protocols for connection management of packet data on signalling channels which is 
applied on the air interface: the 

• PDSSl (Packet Data on Signalling channels Service 1) protocol, and the 

• PDSS2 (Packet Data on Signalling channels Service 2) protocol. 

Both are protocols of the Connection Management (CM) sublayer (see GSM 04.07). 

PDSSl and PDSS2 transactions can be active in parallel to other CM transactions. 

A PDSS 1 transaction may be initiated by the mobile station or the network. A PDSS2 transaction shall only be 
initiated by the mobile station. 

The present document describes the PDSSl and PDSS2 protocols with regard to two peer entities, one in a mobile 
station, the other one in the network. The call control entities are described as communicating finite state machines 
which exchange messages across the radio interface and communicate internally with other protocol (sub)layers.(see 
note[ In the model, for PDSSl, for each Transaction Identifier (TI) value there are two protocol entities in the mobile 
station and two protocol entities in the network: one which may originate a transaction and one which may use the 
transaction originated bt its peer entity; the protocol entity receiving messages with a given TI and TI flag value x may 
send messages with equal TI value and with TI flag value (1-x) mod 2. The originator uses TI flag value 0. A protocol 
entity is idle (also called: in the idle phase) until it has received a message from its peer entity or lower or higher layers 
have passed an abstract service primitive to it. 

[NOTE: Text not yet approved for this version] . 

In particular, the 

- PDSSl protocol uses the MM and RR sublayer specified in GSM 04.08, and the 

- PDSS2 protocol uses the RR sublayer specified in GSM 04.08. 

This description in only normative as far as the consequential externally observable behaviour is concerned. 

Certain sequences of actions of the two peer entities compose "elementary procedures" which are used as a basis for the 
description in the present document. These elementary procedures are defined in section 6 and 7. 

NOTE: Whereas PDSSl provides connections between mobile station and MSC, PDSS2 provides connections 
between the mobile station and the PDSS2 support node, see GSM 03.63. 

The mobile station receives on lower sublayers information from the network whether the mobile station is allowed to 
establish a PDSSl and/or PDSS2 connection. The network is informed by the mobile station in the classmark whether 
the mobile station supports PDSSl and/or PDSS2. 
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The PDSSl and PDSS2 protocols may use the main signalling link or the slow associated signalling link for 
communication, always on the SAP with SAPI=0 and in acknowledged mode (for the definition of these terms, see 
GSM 04.06). It is informed by the network whether it is allowed to establish a PDSSl and/or PDSS2 connection by 
sending the SETUP and/or the IMMEDIATE SETUP message on the main signalling link and/or slow associated 
signalling link. If the mobile station supports PDSSl and/or PDSS2, it shall be able to receive messages of the 
supported protocol(s) on both data links. Once a protocol entity in the mobile station has received a message, the mobile 
station shall send any further message pertaining to the same transaction on the data link on which it had received the 
last message. 



6 Elementary procedures for PDSS1 

6.1 Overview 

The elementary procedures for PDSS 1 may be grouped into the following classes: 
PDSSl establishment procedures. 
PDSSl termination procedures. 
PDSSl information phase procedures. 

6.2 Procedures for establishment of a PDSS1 connection 

The PDSSl protocol entity in the mobile station or network in the idle phase shall on request of higher layers to 
establish a connection, analyse the request: the request contains all information necessary for the SETUP message and 
an indication whether the main or slow associated data link is to be used. The PDSSl protocol entity shall then verify 
whether: 

1) use of the indicated link for PDSSl is possible and allowed; 
and ask the MM sublayer whether: 

2) establishment of a PDSSl connection is possible and allowed. 

If one of these conditions is not fulfilled, the request is rejected. 

If the MM connection establishment is possible and allowed and the use of the indicated link is possible and 
allowed, the PDSSl protocol entity asks the MM sublayer to establish an MM connection. The request 
contains a SETUP message to be transferred to the peer entity. The request from higher layers may already 
contain data to be transferred which does not exceed a maximum allowed length. In this case the data is 
included in the SETUP message. 

If the MM connection establishment fails or is rejected, the PDSSl protocol entity aborts the establishment 
and gives an appropriate information to higher layers; it then returns to the idle phase. 

An idle PDSS 1 protocol entity shall on receipt of a SETUP message inform higher layers. If the SETUP message 
contained a data part, it passes the data part to higher layers and then continues as follows: 

- If higher layers accept the estabUshment, the PDSS 1 protocol entity shall send a SETUP ACKNOWLEDGE 
message to its peer entity and enter the PDSSl information transfer phase. The acceptance from higher layers 
may already contain data to be transferred which does not exceed a maximum allowed length. In this case the 
data is included in the SETUP ACKNOWLEDGE message. 

If higher layers reject the establishment, the PDSSl protocol entity shall send a RELEASE COMPLETE 
message with appropriate cause to its peer entity. 

When a PDSSl has transferred a SETUP message to its peer entity and receives as an answer a SETUP 
ACKNOWLEDGE message, it informs higher layers and enters the PDSSl information transfer phase. 

Abnormal cases 
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1) If during the establishment of a PDSS 1 connection higher layers decide to abort the establishment, the PDSS 1 
protocol entity shall react as specified in subclause 6.3. 

2) If during the establishment of a PDSSl connection a lower layer failure occurs, the PDSSl protocol entity shall 
abort the establishment and inform higher layers. 

3) If the request from higher layers to establish a connection contained data with more than the maximum allowed 
length, the protocol entity shall reject the request with appropriate cause. 

4) If the response from higher layers to accept a connection contained data with more than the maximum allowed 
length, the protocol entity shall reject the response with appropriate cause and then wait for further action from 
higher layers. 

5) If after having informed higher layers that a SETUP has been received, no valid response was received from 
higher layers within 5 seconds, the protocol entity shall send a RELEASE COMPLETE message to its peer 
entity and inform higher layers that the connection establishment has been aborted. 

6) If after having sent the SETUP message, no valid response was received from the peer entity within 10 + 
10-T200-(N DIV N201) seconds (where N is the number of octets the SETUP message consisted of and T200 
and N201 are as defined in GSM 04.06 for the used channel), the protocol entity shall send a RELEASE 
COMPLETE message to its peer entity and inform higher layers that and why the connection establishment has 
been aborted. 

6.3 Procedures for release and termination of a PDSS1 
connection 

If during the establishment or information phase of a PDSS 1 connection higher layers request to abort the establishment 
or to terminate the connection, the PDSSl protocol entity: 

if it has sent or received the SETUP message, shall send a RELEASE COMPLETE message and then ask MM to 
release the MM connection; the request from higher layers may contain data to be transferred which does not 
exceed a maximum allowed length; in this case the data shall be included in the RELEASE COMPLETE 

message; 

otherwise shall ask MM to release the MM connection. 

If during the establishment or information phase of a PDSS 1 connection a PDSS 1 protocol entity receives a RELEASE 
COMPLETE message from its peer entity, it shall inform higher layers and ask MM to release the MM connection. If 
the RELEASE COMPLETE message contains a data part, the data part is passed to higher layers. 

Abnormal cases: 

If the request from higher layers to abort or terminate the connection contained data with more than the maximum 
allowed length, the protocol entity shall send a RELEASE COMPLETE message without data part to its peer entity, and 
inform higher layers about the situation. 

6.4 Procedures for the information phase of a PDSS1 
connection 

During the information phase of a PDSS 1 connection, higher layers may request the transfer of data which does not 
exceed a maximum allowed length. The PDSSl protocol entity then sends the data to its peer entity in a DATA 

message. 

NOTE: Higher layers may apply activity supervision and, e.g., release a PDSSl connection when it has been idle 
for a longer period. 

Abnormal cases: 

1) If during the information phase of a PDSS 1 connection, a lower layer failure occurs, the PDSS 1 protocol entity 
informs higher layers that the data transfer is suspended; if possible and allowed, the PDSSl protocol entity asks 
MM to re-establish the MM connection. If the re-establishment is successful, the PDSSl protocol entity proceeds 
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as defined in subclause 6.4. 1 . If the re-establishment is unsuccessfiil, higher layers are informed that the 
connection is aborted. 

2) If during the information phase of a PDSS 1 connection, the PDSS 1 protocol entity becomes aware that too much 
data is waiting for transmission ("congestion condition"), it informs higher layers that the data transfer is 
suspended. If the PDSSl protocol entity later becomes aware that the congestion condition no more exists, it 
informs higher layers that data transfer can be resumed. 

3) If the request from higher layers to transfer data contained data with more than the maximum allowed length, the 
protocol entity shall reject the request with appropriate cause. 



6.4.1 Resumption of a connection 

During a connection, after a radio link failure the MS shall try to initiate CM re-establishment. If a cell supporting re- 
establishment has been found and the CM re-establishment has been accepted by MM, the MS shall try to resume the 
PDSSl connection: 

When the MS receives a message with the transaction identifier of the PDSSl connection, it shall: 

if it is a PDSS 1 DATA message, implicitly resume that connection; 

if it is a PDSS 1 SETUP message, release that connection and treat the SETUP as the first message of a new 
transaction; 

- if it is a PDSS 1 RELEASE COMPLETE message, release that connection; 

if it did not yet perform such a release or implicit resumption, send a PDSS 1 RESUME REQUEST which may 
be: 

- explicitly acknowledged by the network with a PDSSl RESUME ACK, or 
implicitly accepted by the network with transmission of a DATA message, or 
implicitly rejected by the network with the transmission of a PDSSl SETUP, or 

explicitly rejected by the network with the transmission of a PDSS 1 RELEASE COMPLETE message; 
(all these messages with the same transaction identification). 

7 Elementary procedures for PDSS2 

7.1 Overview 

The elementary procedures for PDSS2 may be grouped into the following classes: 
PDSS2 establishment procedures. 
PDSS2 termination procedures. 
- PDSS2 information phase procedures. 

7.2 Procedures for establishment of a PDSS2 connection 

The PDSS2 protocol entity in the mobile station in the idle phase shall on request of higher layers to establish a 
connection, analyse the request: the request contains all information necessary for the IMMEDIATE SETUP message 
and an indication whether the main or slow associated data link is to be used. The PDSS2 protocol entity shall then 
verify whether: 

1) use of the indicated link for PDSS2 is possible and allowed; 

and whether 
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2) establishment of a PDSS2 connection is possible and allowed. 

If one of these conditions is not fulfilled, the request is rejected. 

If the PDSS2 connection establishment is possible and allowed and the use of the indicated link is possible 
and allowed, the PDSS2 protocol entity asks the RR sublayer to establish an RR connection. The request 
contains an IMMEDIATE SETUP message to be transferred to the peer entity. The request from higher 
layers may already contain data to be transferred which does not exceed a maximum allowed length. In this 
case the data is included in the IMMEDIATE SETUP message. 

If the RR connection establishment fails or the PDSS2 connection establishment is rejected, the PDSS2 
protocol entity aborts the establishment and gives an appropriate information to higher layers; it then returns 
to the idle phase. 

An idle PDSS2 protocol entity in the network shall on receipt of an IMMEDIATE SETUP message inform higher 
layers. If the IMMEDIATE SETUP message contained a data part, it passes the data part to higher layers and then 
continues as follows: 

- If higher layers accept the establishment, the PDSS2 protocol entity shall send a SETUP ACKNOWLEDGE 
message to its peer entity and enter the PDSS2 information transfer phase. The acceptance from higher layers 
may already contain data to be transferred which does not exceed a maximum allowed length. In this case the 
data is included in the SETUP ACKNOWLEDGE message. 

If higher layers reject the establishment, the PDSS2 protocol entity shall send a RELEASE COMPLETE 
message with appropriate cause to its peer entity. 

When a PDSS2 protocol entity in the mobile station has transferred an IMMEDIATE SETUP message to its peer entity 
and receives as an answer a SETUP ACKNOWLEDGE message, it informs higher layers and enters the PDSS2 
information transfer phase. 

Abnormal cases 

1) If during the establishment of a PDSS2 connection higher layers decide to abort the establishment, the PDSS2 
protocol entity shall react as specified in subclause 6.3. 

2) If during the establishment of a PDSS2 connection a lower layer failure occurs, the PDSS2 protocol entity shall 
abort the establishment and inform higher layers. 

3) If the request from higher layers to establish a connection contained data with more than the maximum allowed 
length, the protocol entity shall reject the request with appropriate cause. 

4) If the response from higher layers to accept a connection contained data with more than the maximum allowed 
length, the protocol entity shall reject the response with appropriate cause and then wait for further action from 
higher layers. 

5) If after having informed higher layers that an IMMEDIATE SETUP has been received, no valid response was 
received from higher layers within 5 seconds, the protocol entity shall send a RELEASE COMPLETE message 
to its peer entity and inform higher layers that the connection establishment has been aborted. 

6) If after having sent the IMMEDIATE SETUP message, no valid response was received from the peer entity 
within 10 seconds, the protocol entity shall send a RELEASE COMPLETE message to its peer entity and inform 
higher layers that and why the connection establishment has been aborted. 

7.3 Procedures for release and termination of a PDSS1 
connection 

These procedures are identical to those specified for PDSSl in subclause 6.3. 
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7.4 Procedures for the information phase of a PDSS2 
connection 

During the information phase of a PDSS2 connection, higher layers may request the transfer of data which does not 
exceed a maximum allowed length. The PDSS2 protocol entity then sends the data to its peer entity in a DATA 
message. 

NOTE: Higher layers may apply activity supervision and, e.g., release a PDSS2 connection when it has been idle 
for a longer period. 

Abnormal cases: 

1) During a PDSS2 connection; 

(A) after a change of the radio channel (assignment or handover) and the corresponding L2 SAPI establishment or 
re-establishment (at return to the old channel) the MS shall regard the PDSS2 connection as suspended. It shall 
then try to resume the connection: 

- When the MS receives a message with the transaction identifier of the PDSS2 connection, it shall 

if it is a PDSS2 DATA message, implicitly resume that connection; 

- if it is a PDSS2 RELEASE COMPLETE message, release that connection. 

If the MS did not yet perform such a release or implicit resumption, it shall send a PDSS2 RESUME 
REQUEST which may be: 

- explicitly acknowledged by the network with a PDSS2 RESUME ACK, or 
implicitly accepted by the network with transmission of a DATA message, or 

explicitly rejected by the network with the transmission of a PDSS2 RELEASE COMPLETE message; 

(all these messages with the same transaction identification). 

NOTE: After having transferred the HANDOVER COMPLETE or ASSIGNMENT COMPLETE message, layer 
two will schedule the remaining part of an PDSS2 message, if there is any, for transmission, so that the 
network layer 3 may receive a PDSS2 message after the change of radio channel which was required to 
be transferred by the mobile station PDSS2 protocol entity before it received the indication about the 
channel change. Cf. GSM 04.06. 

(B) after a radio link failure the MS shall regard the PDSS2 connection as suspended. It shall then decide to abort the 
connection or to resume it. 

In order to resume it, the RR sublayer is requested to establish an RR connection. There may be further requests 
for RR connection establishment, e.g. for CM re-establishment; these shall prevail. The further proceeding is as 
described below: 

- If there are only request from the PDSS2 sublayer, the MS shall send a PDSS2 RESUME REQUEST relating 
to one of the requesting PDSS2 protocol entities as first layer 3 message. 

Otherwise, and for further PDSS2 entities requesting the resumption, after establishment of the RR 
connection, the MS continues as in (A). 

NOTE: The messages sent by a PDSS2 protocol entity after resumption still use the same transaction identifier 
and TI flag as before. 

2) If during the information phase of a PDSS2 connection, the PDSS2 protocol entity becomes aware that too much 
data is waiting for transmission ("congestion condition"), it informs higher layers that the data transfer is 
suspended. If the PDSS2 protocol entity later becomes aware that the congestion condition no more exists, it 
informs higher layers that data transfer can be resumed. 

3) If the request from higher layers to transfer data contained data with more than the maximum allowed length, the 
protocol entity shall reject the request with appropriate cause. 
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8 Handling of unknown, unforeseen, and erroneous 

protocol data 

8.1 General 

This section specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the receiving 
PDSSl or PDSS2 protocol entity. These procedures are called "error handling procedures", but in addition to providing 
recovery mechanisms for error situations they define a compatibility mechanism for future extensions of the protocols. 

Subclauses 8.1 to 8.8 shall be applied in order of precedence. 

Most error handling procedures are mandatory for the MS. 

Detailed error handling procedures in the network are implementation dependent and may vary from PLMN to PLMN. 
However, when extensions of this protocol are developed, networks will be assumed to have the error handling that is 
indicated in this section as mandatory ("shall") and that is indicated as strongly recommended ("should"). 
Subclauses 8.2, 8.3, 8.4, 8.5 and 8.7.2 do not apply to the error handling in the network applied to the receipt of initial 
layer 3 message: If the network diagnoses an error described in one of these sections in the initial layer 3 message 
received from the mobile station, it shall either: 

try to recognize the classmark and then take further implementation dependent actions, or 

- release the RR-connection. 

Also, the error handling of the network is only considered as mandatory or strongly recommended when certain 
thresholds for errors are not reached during a dedicated connection. 

In this section the following terminology is used: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved" 
in subclause 10, or if its value part violates rules of subclause 10. However it is not a syntactical error that a TLV 
encoded IE specifies in its length indicator a greater length than defined in subclause 10. 

A message is defined to have semantically incorrect contents if it contains information which, possibly 
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural 
part of sections 6 and 7. 



8.2 Message too short 



When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored, see GSM 04.07. 

8.3 Unknown or unforeseen transaction identifier 

The mobile station and network shall answer to a message received with TI value " 111 " by sending a RELEASE 
COMPLETE message with same TI value and cause "invalid transaction identifier value". For a call control message 
received with TI different from "111", the following procedures shall apply: 

a) Whenever a message except a SETUP or RELEASE COMPLETE is received specifying a transaction identifier 
which is not recognized as relating to an active transaction, the receiving entity shall send a RELEASE 
COMPLETE message with cause #81 "invalid transaction identifier value" using the received transaction 
identifier value and remain idle. 

b) When a RELEASE COMPLETE message is received specifying a transaction identifier which is not recognized 
as relating to an active transaction, the MM connection associated with that transaction identifier shall be 
released. 

c) When a SETUP message is received with: 

a transaction identifier which is not recognized as relating to an active transaction, and 
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TI flag value 1 ; 

the receiving entity shall send a RELEASE COMPLETE message with cause "invalid transaction identifier 
value" and not including diagnostics using the received transaction identifier value and remain idle. 

d) When a SETUP message is received specifying a transaction identifier which is recognized as relating to an 
active call or to a call in progress, this SETUP message shall be treated as a message not compatible with the 
protocol state, see subclause 8.4. 

8.4 Unknown or unforeseen message type 

If the protocol entity in the mobile station receives a message with message type not defined for the PD or not 
implemented by the receiver, it shall ignore the message except for the fact that, if an RR connection exists, it shall 
return a STATUS message with cause "message type non-existent or not implemented" and including as diagnostics the 
message type of the message received. 

If the protocol entity in the network receives a message with message type not defined for the PD or not implemented 
by the receiver, it shall ignore the message except that it should return a STATUS message with cause "message type 
non-existent or not implemented" and including as diagnostics the message type of the message received. 

NOTE: A message type not defined for the PD in the given direction is regarded by the receiver as a message 
type not defined for the PD, see GSM 04.07. 

1) If the protocol entity in the mobile station receives a message not compatible with the protocol state, the mobile 
station shall ignore the message except for the fact that, if an RR connection exists, it returns a STATUS 
message with cause "message type not compatible with protocol state" and including as diagnostics the message 
type of the message received. 

If the network receives a message not compatible with the protocol state, the network actions are implementation 
dependent. 

8.5 Non-semantical mandatory information element errors 

When on receipt of a message: 

an "imperative message part" error, or 

a "missing mandatory IE" error; 
is diagnosed or when a message containing: 

a syntactically incorrect mandatory IE, or 

an IE unknown in the message, but encoded as "comprehension required" (see GSM 04.08, subclause 10.5), or 

an out of sequence IE encoded as "comprehension required" (see GSM 04.08, subclause 10.5); 
is received; 

the mobile station shall proceed as follows: 

When the message is not one of the messages listed in section 8.5.1, the mobile station shall ignore the 
message except for the fact that, if an RR connection exists, it shall return a STATUS message with cause 
"invalid mandatory information" and including, if possible, as diagnostics the complete message received 
(this may not be possible, e.g., due to length restrictions). 

the network shall proceed as follows: 

When the message is not one of the message listed in section 8.5.1 the network shall either: 

try to treat the message (the exact further actions are implementation dependent), or 

ignore the message except that it should return a STATUS message with cause "invalid mandatory 
information", possibly including as diagnostics the complete message received. 
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8.5.1 Special cases 

1) If the message is a SETUP message and received by the mobile station, a RELEASE COMPLETE message shall 
be returned with cause "invalid mandatory information" and including, if possible, as diagnostics the complete 
message received (this may not be possible, e.g., due to length restrictions). 

2) If the message is a SETUP message and received by the network, a RELEASE COMPLETE message shall be 
returned with cause "invalid mandatory information" and possibly including as diagnostics the complete message 
received. 

3) If the message is a RELEASE COMPLETE message, it shall be treated as a normal RELEASE COMPLETE 
message. 

4) If the message is a STATUS message and received by the network, a RELEASE COMPLETE message may be 
returned with cause value "invalid mandatory information" and possibly including as diagnostics the complete 
message received. 

8.6 Unknown and unforeseen information elements in the 
non-imperative message part 

8.6.1 Information elements unknown in the message 

The protocol entity shall ignore all information elements unknown in a message which are not encoded as 
"comprehension required". 

8.6.2 Out of sequence information elements 

The MS shall ignore all out of sequence Information elements in a message which are not encoded as "comprehension 
required". 

The network should take the same approach. 

8.6.3 Repeated Information elements 

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information 
element is not specified in section 9 of the present document, only the contents of the information element appearing 
first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of 
information elements is specified, only the contents of specified repeated information elements shall be handled. If the 
limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the 
limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored. 

The network should follow the same procedures. 

8.7 Non-imperative message part errors 

This category includes: 

syntactically incorrect optional Information elements; 
conditional IE errors. 

8.7.1 Syntactically incorrect optional Information elements 

The protocol entity shall treat all optional Information elements that are syntactically incorrect in a message as not 
present in the message. 
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8.8 Messages with semantically incorrect contents 

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of 
sections 6 and 7 are performed. If however no such reactions are specified, the MS shall ignore the message except for 
the fact that, if an RR connection exists, it returns a STATUS message with cause value "semantically incorrect 
message" and including, if possible, as diagnostics the complete message received (this may not be possible, e.g., due to 
length restrictions). 

The network should follow the same procedure except that a status message is not normally transmitted. 



9 MESSAGE FUNCTIONAL DEFINITIONS AND 

CONTENTS 

This section defines the structure of the messages of those layer 3 protocols, that is the PDSSl and PDSS2 protocols. 
Both protocols mostly use the same messages, but have different protocol discriminators, cf. GSM 04.07. 

NOTE: Two different protocol discriminators are used in order to allow the network different routing. 

When a message is only defined for one protocol in one protocol or has restricted use in one protocol (i.e. it is only 
defined in one direction in one protocol but in both directions in the other protocol), this is defined in the subclause 
specifying the message. All messages are standard L3 messages as defined in GSM 04.07. 

Each definition given in the present subclause includes: 

a brief description of the message direction and use; 

a definition in which protocol(s), PDSSl and/or PDSS2 the message is defined and in which direction; 

a table listing the information elements permitted to be in that message and their order of their appearance in the 
message. All information elements that may be repeated are explicitly indicated. Neither the network nor the 
mobile station is allowed to include information elements in a message which are not specified for the message 
or to include the information elements in the message in an order different from the specified order. ( V and LV 
formatted lEs, which compose the imperative part of the message, occur before T, TV, and TLV formatted lEs 
which compose the non-imperative part of the message, cf GSM 04.07.) In a (maximal) sequence of consecutive 
information elements with half octet length, the first information element with half octet length occupies bits 1 to 
4 of octet N, the second bits 5 to 8 of octet N, the third bits 1 to 4 of octet N+1 etc. Such a sequence always has 
an even number of elements. 

For each information element the table indicates: 

1 . if the IE has format T, TV, or TLV, the lEI used by the IE at the indicated position in the message, in 
hexadecimal notation. If the lEI has half octet length, this is specified by a notation representing the lEI as a 
hexadecimal digit followed by a "-" (example: B-); 

2. the name of the information element (which may give an idea of the semantics of the element). The name of 
the information element (usually written in italics) followed by "IE" or "information element" is used in 
GSM 04.08 as reference to the information element within a message; 

3. the name of the type of the information element (which indicates the coding of the value part of the IE), and 
generally, the referenced subsection of subclause 10 describing the value part of the information element; 

4. the presence requirement indication (M or O) for the IE as defined in GSM 04.07. (Presence requirement 
indication C is not used in the present document); 

5. the format of the information element (T, V, TV, LV, TLV) as defined in GSM 04.07; 

6. the length of the information element (or permissible range of lengths), in octets, in the message. This 
indication is normative. However, further restrictions to the length of an IE may be specified elsewhere. 

c) subsections specifying, where appropriate: 

the meaning of, and 
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conditions for; 

absence, repeated occurrence, and/or presence for lEs with presence requirement O in the relevant message 
which together with other conditions specified, define when the information elements shall be included or not, 
what presence, repeated occurrence, and absence of such lEs means. 

Table 9.1/GSM 04.63 summarizes the messages for PDSSl and PDSS2. A letter D ("downhnk") in the column 
corresponding to one of the two protocols specifies that the message is defined in the direction network to mobile 
station for that protocol, a letter U ("uplink") specifies that the message is defined in the direction mobile station to 
network for that protocol; the word "no" specifies that the message is not defined at all for that protocol. 

Table 9.1/GSM 04.63: Messages for PDSSl and PDSS2 



Message 


Reference 


defined for PDSSl 


defined for PDSS2 


DATA 


9.1 


D,U 


D,U 


IMMEDIATE SETUP 


9.2 


no 


U 


RELEASE COMPLETE 


9.3 


D,U 


D,U 


SETUP 


9.4 


D,U 


no 


SETUP ACKNOWLEDGE 


9.5 


D,U 


D,U 


RESUME 


9.6 


U 


U 


RESUME ACK 


9.7 


D 


D 


STATUS 


9.8 


D,U 


D,U 



9.1 DATA 

This message is used to send data to the peer entity. See Table 9.2/GSM 04.63. 
Message type: DATA. 

Protocol/direction: PDSSl in both directions. 
PDSS2 in both directions. 

Table 9.2/GSM 04.63: DATA message 



lEI 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 
GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 
















data 


data 
10.5.3 


M 


LV 


1-249 



9.1.1 



Data 



The length of the data information element (including the length indicator) in the DATA message shall not exceed 25 1 
L octets where L is the number of octets occupied by all other lEs in the message. 
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NOTE: This is due to restrictions of layer 2 (which result from restrictions in GSM 08.56). Due to some reasons, 
usage of long data IE is not recommendable e.g. on the S ACCH or if the A or Ap interface has stronger 
length restrictions. 



9.2 



IMMEDIATE SETUP 



This message is sent by the mobile station to the network in order to initiate the establishment of a PDSS2 connection. 
See Table 9.3/GSM 04.63. 

Message type: IMMEDIATE SETUP. 

Protocol/direction: PDSS2 mobile station to network. 

Table 9.3/GSM 04.63: IMMEDIATE SETUP message 



lEI 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 

GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 




spare half octet 


spare half octet 
10.5.5 


M 


V 


1/2 




ciphering key sequence 
number 


ciphering key sequence 
number 
GSM 04.08, 10.5.3.2 


M 


V 


1/2 




mobile station 
classmark 


mobile station 
classmark 2 
GSM 04.08, 10.5.1.6 


M 


LV 


4 




mobile identity 


mobile identity 
10.5.4 


M 


LV 


2-9 




application 


application 
10.5.1 


M 


V 


1 
















data 


data 
10.5.3 


M 


LV 


1-10 



9.2.1 Ciphering key sequence number 

The ciphering key sequence number shall be set to the value "111" (no key is available). 



9.2.1 



Data 



The length of the data information element (including the length indicator) in the IMMEDIATE SETUP message shall 
not exceed N201 - L, where L is the number of octets all other information elements occupy in the message and N201 is 
as defined in GSM 04.06 for the signalling link used for the transmission of the message. 



£75/ 



3GPP TS 44.063 version 4.0.0 Release 4 



19 



ETSI TS 144 063 V4.0.0 (2001-03) 



9.3 



RELEASE COMPLETE 



This message is sent to the peer entity in order to release the PDSSl or PDSS2 connection. See Table 9.4/GSM 04.63. 
Message type: RELEASE COMPLETE. 
Protocol/direction: PDSSl in both directions. 
PDSS2 in both directions. 

Table 9.4/GSM 04.63: RELEASE COMPLETE message 



lEl 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 

GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 

GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 




cause 


cause 
10.5.2 


M 


LV 


2-248 




data 


data 

10.5.3 


M 


LV 


1-248 


08 


cause 2 


cause 

10.5.2 


O 


TLV 


3-248 



9.3.1 



Data 



The length of the data information element (including the length indicator) in the RELEASE COMPLETE message 
shall not exceed 251 - L octets where L is the number of octets occupied by all other lEs in the message. 

NOTE: This is due to restrictions of layer 2 (which result from restrictions in GSM 08.56). Due to some reasons, 
usage of long data IE is not recommendable e.g. on the S ACCH or if the A or Ap interface has stronger 
length restrictions. 

9.3.2 Cause 2 

This IE is included in the message, if more than one cause has to be reported; it may be repeated in the message, if 
further causes have to be reported. 
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9.4 



SETUP 



This message is sent by a PDSSl protocol entity in order to establish a PDSSl connection. See Table 9.5/GSM 04.63. 
Message type: SETUP. 
Protocol/direction: PDSSl in both directions. 

Table 9.5/GSM 04.63: SETUP message 



lEl 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 
GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 




application 


application 
10.5.1 


M 


V 


1 
















data 


data 
10.5.3 


M 


LV 


1-248 



9.4.1 



Data 



The length of the data information element (including the length indicator) in the SETUP message shall not exceed 
25 1 - L octets where L is the number of octets occupied by all other lEs in the message. 

NOTE: This is due to restrictions of layer 2 (which result from restrictions in GSM 08.56). Due to some reasons, 
usage of long data IE is not recommendable e.g. on the S ACCH or if the A or Ap interface has stronger 
length restrictions. 
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9.5 



SETUP ACKNOWLEDGE 



This message is sent by a PDSSl or PDSS2 protocol entity in order to accept establishment of a connection. See 
Table 9.6/GSM 04.63. 

Message type: SETUP ACKNOWLEDGE. 

Protocol/direction: PDSSl in both directions. 

PDSS2 in both directions. 

Table 9.6/GSM 04.63: SETUP ACKNOWLEDGE message 



lEl 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 
GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 
















data 


data 
10.5.3 


M 


LV 


1-249 



9.5.1 



Data 



The length of the data information element value part in the SETUP message shall not exceed 251 - L octets where L is 
the number of octets occupied by all other lEs in the message. 

NOTE: This is due to restrictions of layer 2 (which result from restrictions in GSM 08.56). Due to some reasons, 
usage of long data IE is not recommendable e.g. on the S ACCH or if the A or Ap interface has stronger 
length restrictions. 
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9.6 RESUME 



This message is sent to the peer entity in order to resume the connection. See Table 9.7/GSM 04.63. 
Message type: RESUME. 

Protocol/direction: PDSS 1 in mobile to network direction. 
PDSS2 in mobile to network direction. 

Table 9.7/GSM 04.639.6: RESUME 



lEI 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 

GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 




spare half octet 


spare half octet 
10.5.5 


M 


V 


1/2 




ciphering key sequence 
number 


ciphering key sequence 
number 
GSM 04.08, 10.5.3.2 


M 


V 


1/2 




mobile station 
classmark 


mobile station 
classmark 2 
GSM 04.08, 10.5.1.6 


M 


LV 


4 




mobile identity 


mobile identity 
10.5.4 


M 


LV 


2-9 



9.6.1 Ciphering key sequence number 

The ciphering key sequence number shall be set to the value "111" (no key is available) in case of PDSS2. 
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9.7 RESUME ACK 



This message is sent to the peer entity in order to acknowledge resumption of the connection. See Table 9.8/GSM 
04.63. 

Message type: RESUME ACK. 

Protocol/direction: PDSS 1 in network to mobile direction. 

PDSS2 in network to mobile direction. 

Table 9.8/GSM 04.63: RESUME ACK 



lEl 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 
GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 
GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 



9.8 STATUS 

This message is sent by a PDSSl or PDSS2 protocol entity in order to inform its peer entity about an error situation. See 
Table 9.7/GSM 04.63. 

Message type: STATUS. 

Protocol/direction: PDSSl in both directions. 

PDSS2 in both directions. 

Table 9.9/GSM 04.63: STATUS message 



lEI 


information element 


type / reference 


presence 


format 


length 




protocol discriminator 


protocol discriminator 
GSM 04.07, 11.2.1 


M 


V 


1/2 




transaction identifier 


transaction identifier 

GSM 04.07, 11.2.3 


M 


V 


1/2 




message type 


message type 
10.4 


M 


V 


1 




cause 


cause 
10.5.2 


M 


LV 


2-248 


08 


cause 2 


cause 

10.5.2 


O 


TLV 


3-248 



9.8.1 Cause 2 

This IE is included in the message, if more than one cause has to be reported; it may be repeated in the message, if 
further causes have to be reported. 
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10.1 Overview 

Within the Layer 3 protocols defined, every message is a standard L3 message as defined in GSM 04.07. 

10.2 Protocol Discriminator 

The Protocol Discriminator (PD) and its use are defined in GSM 04.07. GSM 04.08 defines the protocols relating to the 
PD values: 

bits 4 3 2 1 

00 10 PDSSl protocol 
10 PDSS2 protocol. 

10.3 Transaction identifier 

Bits 5 to 8 of the first octet of every message belonging to the PDSSl and PDSS2 protocols contain the transaction 
identifier (TI). The transaction identifier and its use are defined in GSM 04.07. 



10.4 IVIessage Type 



The message type IE and its use are defined in GSM 04.07. Table 10.1/GSM 04.63 define the value part of the message 
type IE used in the PDSSl and PDSS2 protocols. 

Table 10.1/GSM 04.63: Message types for PDSSl and PDSS2 



1 8 


7 


6 


5 


4 


3 


2 


1 




1 


X 


1 


1 














DATA 


1 


X 


1 


1 











1 


IMMEDIATE SETUP 


1 


X 


1 


1 








1 





RELEASE COMPLETE 


1 


X 


1 


1 








1 


1 


SETUP 


1 


X 


1 


1 





1 








SETUP ACKNOWLEDGE 


1 


X 


1 


1 





1 





1 


RESUME 


1 


X 


1 


1 





1 


1 





RESUME ACK 


1 


X 


1 


1 





1 


1 


1 


STATUS 



Bit 8 is reserved for possible future use as an extension bit, see GSM 04.07. 

Bit 7 is reserved for the send sequence number in PDSSl and PDSS2 messages sent from the mobile station. In PDSSl 
and PDSS2 messages sent from the network an, bit 7 is coded with a "0". See GSM 04.07. 

10.5 Other information elements 

For coding of other lEs, the rules defined in GSM 04.08 apply. 

10.5.1 Application 

The purpose of the application information element is to indicate the application that requested the PDSSl or PDSS2 
connection to the peer entity. 

The application information element value part has a length of 1 octets. The value part is coded as shown below: 

87654321 

+ + 

I 1 I application indication | octet 1 

I ext I 

+ 1 + 

Figure 10.1/GSM 04.63: application indication information element 
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Table 10.2/GSM 04.63: application indication information element 



application 


indication (7 bits) 




bit 


7 




6 




5 4 3 2 1 

1 


X.25 
IP 


all other values indicate unknown 


applications 



10.5.2 Cause 

The purpose of the cause information element is to describe the reason for generating certain messages and to provide 
diagnostic information in the event of procedural errors. 

The cause information element value part has a minimal length of 1 octets. No upper length limit is specified except for 
that given by the maximum number of octets in a L3 message (see GSM 04.06); further rules in the present document 
may further restrict the length of the IE in a message. 

The value part is coded as shown below: 

87654321 



I 1 

I ext I cause value 

I 

I diagnostic (s) if any 



octet 1 

octet 2* 
octet N* 



Figure 10.2/GSI\/I 04.63: cause information element 
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Table 10.3/GSM 04.63: cause information element 



Cause 


value 


(octet 1) 






Bits 








7 


6 


5 


4 


3 


2 


1 



















1 


1 


Illegal 














1 





1 


IMEI no 














1 


1 





Illegal 











1 











Service 











1 








1 


Applica 
protoco 











1 





1 





RR conn 








1 











1 


Network 








1 





1 


1 





Congest 





1 

















Service 





1 














1 


Request 
not s 





1 











1 





Service 
out o 





1 








1 


1 





Call ca 





1 


1 














} 






to 








} ret 





1 


1 


1 


1 


1 


1 


} 


1 





1 


1 


1 


1 


1 


Semanti 


1 


1 

















Invalid 


1 


1 














1 


Message 
or no 


1 


1 











1 





Message 
the pro 


1 


1 











1 


1 


Informa 
or no 


1 


1 








1 





1 


Message 
the p 


1 


1 





1 


1 


1 


1 


Protoco 



MS 
t accepted 

ME 

not authorized 
tion not supported on the 
1 
ection aborted 

failure 
ion 

option not supported 
ed service option 
ubscribed 

option temporarily 
f order 
nnot be identified 

ry upon entry into a new cell 

cally incorrect message 
mandatory information 
type non-existent 

t implemented 
type not compatible with 

tocol state 

tion element non-existent 

t implemented 
not compatible with 

rotocol state 

1 error, unspecified 

Any other value received 

shall be treated as an unspecific information 



Diagnostics (octet 2 ff) 

This field may contain a message or information 

element 



10.5.3 Data 

The purpose of the data information element is to transport data to the peer entity. Within the scope of the present 
document the content of the data information field is an array of octets. 

The data information element has a minimum length of octets. No upper length limit is specified except for that given 
by the maximum number of octets in a L3 message (see GSM 04.06); further rules in the present document may further 
restrict the length of the IE in a message. 

10.5.4 Mobile identity 2 

The purpose of the mobile identity information element is to provide either the international mobile subscriber identity, 
IMSI, the temporary mobile subscriber identity, TMSI, the international mobile equipment identity, IMEI, the 
international mobile equipment identity together with the software version number, lEMISV or the Anonymous Mobile 
Station Identity (AMSI). 

The IMSI shall not exceed 15 digits, the TMSI and The AMSI is 4 octets long. 

The mobile identity 2 IE is used in the establishment of a PDSS2 connection. The mobile station shall select the mobile 
identity type as follows: If the application requests it, the AMSI is used. Otherwise the TMSI shall be used if it is 
available. The IMSI shall be used in cases where no TMSI is available. 
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The mobile identity information element is coded as shown below: 



_L 



6 5 4 3 
Mobile Identity lEI 



Length of mobile identity contents 

I odd/ I 
Identity digit 1 | even | Type of identity 

indie I 



Identity digit p+1 



-1 



Identity digit p 



octet 1 
octet 2 
octet 3 

octet 4* 



Figure lO.S/GSIVI 04.63: Mobile Identity 2 iniormation element 
Table 10.4/GSM 04.63: Mobile Identity 'information element 



Type of identity (octet 3) 

Bits 

3 2 1 

1 IMSI 

10 TMSI 

10 1 AMSI 

All other values are reserved. 

Odd/even indication (octet 3) 

Bit 

4 

even number of identity digits and also when 
the TMSI is used 

1 odd number of identity digits 

Identity digits (octet 3 etc.) 

For the IMSI this field is coded using 

BCD coding. If the number of identity digits is even 

then bits 5 to 8 of the last octet shall be filled 

with an end mark coded as "1111". 

If the mobile identity is the TMSI then bits 5 to 8 of 
octet 3 are coded as "1111" and bit 8 of octet 4 is the 
most significant bit and bit 1 of the last octet the 
least significant bit. The coding of the TMSI is left 
open for each administration. 

If the mobile identity is the AMSI then bits 5 to 8 of 
octet 3 are coded as "1111" and bit 8 of octet 4 is the 
most significant bit and bit 1 of the last octet the 
least significant bit. The coding of the AMSI is further 
defined in TS GSM 03.03. 



10.5.5 Spare Half Octet 

This element is used in the description of messages in section 9 when an odd number of half octet type 1 information 
elements are used. This element is filled with spare bits set to zero and is placed in bits 5 to 8 of the octet unless 
otherwise specified. 
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Annex A (informative): 
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